A Compiler for Ordered Logic Programs* 
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Abstract 

This paper describes a system, called PLP, for com- 
piling ordered logic programs into standard logic pro- 
grams under the answer set semantics. In an ordered 
logic program, preference information is expressed at 
the object level by atoms of the form s -< t, where s 
and t are names of rules. An ordered logic program 
is transformed into a second, regular, extended logic 
program wherein the preferences are respected, in that 
the answer sets obtained in the transformed theory cor- 
respond with the preferred answer sets of the original 
theory. Since the result of the translation is an ex- 
tended logic program, existing logic programming sys- 
tciiiis can be used as uudei lying reasoning engine. — fn - 
p articular, PLP is conceived as a front end to the logic 



programming systems dlv and smodels. 

General Information 

Several approaches have been introduced in recent 
years undertaking the ability to express preference in- 



formalisms ( 


Baader & Hollunder 1993|; Brewka 1994 


Brewka 1996 


; Selfond & Son 1997 ; Zhang & Foo 1997 


Brewka & Eiter 1999). However, most of these methods 



treat preferences at the meta-level and require a change 
of the underlying semantics. For instance, incorporat- 
ing explicit orderings of logic programming rules is re- 
alized by modifying the fixed-point conditions charac- 
terizing answer sets or well-founded consequences. As 
a result, implementations need in general fresh algo- 
rithms and cannot rely on existing systems computing 
the regular (unordered) formalisms. 

In this paper, we describe a compiler, PLP, for pre- 
ferred answer sets which evades the need of new algo- 
rithms. PLP is based on an approach for expressing 
preference information within the framework of stan- 
dard answer set semantics. The general techniq ue is 



described in (Delgrande, Schaub, & Tompits 2000) and 
derives from a methodology for a ddressing preferences 



in de fault logic first proposed in ( Delgrande fc Schaub 



1997 ). We begin with an ordered logic program, which is 



an extended logic program in which rules are named by 



unique terms and in which preferences among rules are 
given by a new set of atoms of the form s -< t, where s 
and t are names. Such an ordered logic program is then 
transformed into a second, regular, extended logic pro- 
gram wherein the preferences are respected, in the sense 
that the answer sets obtained in the transformed theory 
correspond to the preferred answer sets of the original 
theory. The approach is sufficiently general to allow the 
specification of preferences among preferences, prefer- 
ences holding in a particular context, and preferences 
holding by default. 

PLP has been implemented in Prolog and serve s as a 
front-end for the logic progr amming systems dlv ( Eiter 
et al. 1997 ) and smodels ( Niemela, fc Simons 1997^ ; 
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it has been developed under the ECLiPSe Constraint 
Logic Programming System and comprises roughly 300 
lines of code. It runs under any operating systems 
for which dlv or smodels are executable, provided 
ECLiPSe Prolog is available. Apart from the pretty- 
printer, we only employ standard Prolog programming 
constructs. 

Description of the System 

The logic programming systems dlv and smodels rep- 
resent state-of-th e-art implementations o f the stable 
model semantics (Gelfond & Lifschitz 1988), the former 
system also admitting strong negation and disjunctive 
rules. As well, several front-ends for these systems have 
been developed with the purpose of providing direct 
encodings of advanced reasoning problems, like, e.g. , 
diagnostic reason ing or planning ( Eiter et al. 199S| ; 
Eiter et al. 2000| ). 

PLP realizes a further front-end for these systems, 
handling ordered logic programs. The structure of PLP 
is divided into five files: 

• The actual compiler is contained in the file pref .pi 
(or pref a;, pi, where x is the actual version number). 

• The file grounder . pi takes care of programs with 
variables and non-atomic term structures. 

• The file pp . pi provides a pretty-printer for the files 
resulting from the compilation. (This module re- 
lies on features of ECLiPSe for transforming Prolog's 
variables like _4711 into more readable ones like X. 



This is necessary in view of processing the hies with 
dlv and smodels.) 

• The files dlv.pl and smodels.pl contain code spe- 
cific to the respective logic programming systems. 

The general function of PLP works in three stages: 

1. loading the compiler (which charges also the Prolog 
files pp.pl, grounder.pl, dlv.pl, and smodels.pl); 

2. compiling the original Prolog file (the compiler is 
pretty verbose and displays also intermediate versions 
of the compiled program); 

3. call of dlv or smodels. 

The present version of PLP is written for the following 
releases of dlv and smodels: 

dlv : release from November 24, 1999. 

smodels: version 1.12, including parse-1.3. Adap- 
tions for lparse and pparse (and thus smodels-2) 
are under development. 

The current prototype of PLP can be found at the 
following URL: 

http : / / www . cs . uni-potsdam . de/~torsten/plp/. 

Applying the System 
Methodology 

As part of the general logic programming paradigm, 
ordered logic programs deal with knowledge represen- 
tation tasks in a declarative way. As well, the method- 
ology of representing problems using ordered logic pro- 
grams is essentially the same as the methodology of rep- 
resenting problems in terms of standard logic programs. 
However, the admission of explicit preference relations 
within an ordered logic programs offers a convenient 
way to represent problems which would otherwise be 
somewhat tedious to handle. 

Specifics 

PLP offers several methods how preferences can be en- 
coded. To begin with, preferences between single rules 
can be specified. As well, programs can contain prefer- 
ence relations between sets of (names of) rules. Fi nally, 



in addition to the general appro ach discussed in (Del- 
grande, Schaub, & Tompits 200C), our compiler can also 
handle rules with variables 



Preferences Between Single Rules. The specifi- 
cation of preference relations between single rules is 
achieved by associating names to certain (or all) rules 
of the given program, and by using atoms of the form 
n -< n! ', where n,n' are names of rules, to express a 
preference relation between rules named n and n', re- 
spectively. Informally, atom n -< n' states that the rule 
named n has higher priority than the rule named n'. 
Preference atoms may occur in any program rules, thus 



defining preference information in a dynamic way. For 
instance, the rule 

n -< n <— p, not q 

expresses preference of rule named n' over rule named 
n in case that p is known and q is not known. Observe 
that p and q may themselves be preference atoms, or 
rely on other preference atoms. 

Let us illustrate the use of preference information be- 
tween single rules by the following program II, rep- 
resenting the well-known penguin-birds-example, but 
where an additional preference between two conflicting 
rules is specified: 

penguin(tweety) <— 
bird(tweety) <— 
f*i : flies(tweety) 



-iflies(tweety) 



ni -< n 2 



bird(tweety) , 
not ->flies(tweety) 

penguin(tweety) , 
not flies(tweety) 



Rules r\ and r 2 are associated with names n\ and n 2 , 
which are constants in the object language. It is not 
necessary to name each rule in a program, but only 
those which occur as an argument in a preference atom. 
Fact ni -< n 2 <— expresses that r 2 has higher priority 
than n . Without this preference information, this pro- 
gram has two answer sets, one containing flies(tweety) 
and the other containing ->flies(tweety). 

The above program II is expressed in our syntax as 
follows: 

penguin (tweety) . 
bird(tweety) . 

flies (tweety) :- name(l), 

not neg flies (tweety) , 
bird(tweety) . 

neg flies (tweety) :- name (2), 

not flies (tweety) , 
penguin (tweety) . 

1 < 2. 

The atoms name(l) and name (2) are used to refer to 
the names of r\ and r 2 , respectively. Compiling the file 
yields the following result: 

penguin (tweety) . 
bird(tweety) . 

flies (tweety) :- ap(l) . 

ap(l) :- ok(l) , not not_f lies (tweety) , 
bird(tweety) . 

ap(2) :- ok(2) , not flies (tweety) , 
penguin (tweety) . 

name(N), oko(N, 1), oko(N, 2). 



ok(N) 

bl(l) 
bl(l) 
bl(2) 
bl(2) 



ok(l) , not_f lies (tweety) . 

ok(l), not bird (tweety) . 

ok(2) , flies (tweety) . 

ok(2) , not penguin (tweety) . 



not_flies(tweety) :- ap(2) . 

prec(l, 2). 

oko(N, N) :- name(N). 

oko(N, M) :- name(N), name(M), 
not prec(N, M) . 

oko(N, M) :- name(N), name(M), 
prec(N, M) , ap(M) . 

oko(N, M) :- name(N), name(M), 
prec(N, M) , bl(M) . 

name (2) . 
name(l) . 

What is the meaning of the newly introduced predi- 
cates and rules? The predicates ap/1, bl/1, ok/1, and 
oko/2 control the order of the applications of the orig- 
inal rules and guarantee that the intended preference 
relation is respected. Informally, ap (n) and bl (n) ex- 
press that the rule named n is already known to be "ap- 
plied" or "blocked", respectively, whilst ok(n) states 
that it is acceptable to apply the rule associated with 
name n. Atom ok(n) is accepted on the basis of the 
auxiliary predicates oko/2. As well, the order relation 
< is captured by the predicate prec/2. 

Piping the result into dlv yields the following answer 
set: 

{true, name(l), name(2), penguin(tweety) , 
bird(tweety) , ok(2) , oko(l,l), oko(2,l), 
oko(2,2), prec(l,2), neg_prec(2, 1) , 
ap(2), neg_f lies(tweety) , oko(l,2), 
ok(l), bl(l)} 

We obtain a single answer set that corresponds to 
the second answer set for the example without prefer- 
ences. Also, it includes the additional atoms that stem 
from the necessary preference-handling rules, as dis- 
cussed above. If the user desires, these special-purpose 
atoms may be suppressed from the output by using the 
option "nice" in the execution command. 

Dynamic Preferences with Variables. PLP can 

also deal with parametrized names. The use of vari- 
ables admits the specification of conditional, context- 
sensitive preferences. Consider the following example: 

bird(tweety) . penguin (tweety) . water_shy (tweety) . 
bird(opus) . emu(opus) . 
bird(scully) . toy(scully) . 

flies (X) :- name(rl(X)), not neg flies(X), 
bird(X) . 

neg flies (X) :- name(r2(X)), not flies(X), 
penguin(X) . 

neg flies(X) :- name (r3(X) ) , not flies(X), emu(X) . 

neg flies(X) :- name(r4(X)), not flies(X), toy(X) . 

(rl(X) < r2(X)) :- not water_shy(X) . 

(rl(X) < r3(X)). 

For treating such programs, they are preprocessed in 
two steps: 

1. rules with variables are replaced by their ground in- 
stances; 



2. names with a complex term structure are turned 
into constants (eg. name(r(f (c) ) ) is turned into 
name(rjf_c)). 

The above program yields the following answer sets: 

{bird(tweety) , bird(opus) , bird(scully) , 
penguin (tweety) , water_shy (tweety) , 
emu (opus) , toy(scully) , f lies(tweety) , 
flies (scully) , neg_f lies (opus) } 

{bird(tweety) , bird(opus) , bird(scully) , 
penguin (tweety) , water_shy (tweety) , 
emu (opus) , toy(scully) , f lies(scully) , 
neg_f lies (tweety) , neg_f lies (opus)} 

{bird(tweety) , bird(opus) , bird(scully) , 
penguin (tweety) , water_shy (tweety) , 
emu (opus) , toy(scully) , f lies(tweety) , 
neg_f lies (opus) , neg_f lies (scully)} 

{bird(tweety) , bird(opus) , bird(scully) , 
penguin (tweety) , water_shy (tweety) , 
emu (opus) , toy(scully) , neg_f lies (tweety) , 
neg_f lies (opus) , neg_f lies (scully)} 

By using the option "nice" , we suppressed the special- 
purpose atoms in the displayed output. 

Set-ordered Programs. Generalizing the idea of 
preferences between rules, set-ordered programs admit 
the specification of preference information between sets 
of rules. Informally, if set M' is preferred over set M, 
then M is considered after all rules in M' are found to 
be applicable, or some rule in M' is found to be inap- 
plicable. 

In order to express preferences between sets of rules, 
set-ordered programs associate unique names to sets 
of rules and express preference information in terms of 
atoms m -Km 1 ', where m, m! are names of sets of rules. 
Following our previous convention, m -< m' states that 
the set named m' is preferred over the set named m. 

The idea behind sets of preferences is illustrated by 
the following example dealing with "car features" : 

Consider where in buying a car one ranks the price 
("expensive") over safety features ("safe") over 
power ("powerful"), but safety features together 
with power is ranked over price. 

This is expressed by the following set-ordered program: 

expensive :- name(e), not neg expensive, 
powerful :- name(p), not neg powerful, 
safe :- name(s), not neg safe. 

neg expensive :- powerful, safe, 

neg powerful :- expensive, safe, 
neg safe :- expensive, powerful 

ml : [p] . 

m2 : [s] . 

m3 : [e] . 

m4 : [p,s] . 

ml < m2. 
m2 < m3 . 
m3 < m4. 



Here, ml is the name of the set [p] comprising the rule 
named p (and analogously for m2, m3, and m4). More 
generally, sets are expressed in an extensional way by: 

<set-name> : [<rule-name> , . . . , <rule-name>] . 

As well, preferences on individual rules are expressed 
via the corresponding singleton sets. 

Engaging our compiler and piping the described pro- 
gram into dlv, we obtain the following answer set: 

{powerful, safe, neg_expensive} 

Again, in the displayed result we suppressed the special- 
purpose atoms by engaging the option "nice". 

Users and Usability 

As for any logic programming system, proper usage of 
PLP requires the user's ability to formalize a given prob- 
lem adequately in terms of an ordered (or set-ordered) 
logic program. However, as already pointed out above, 
the added benefit of ordered logic programs to allow 
the explicit specification of certain domain knowledge 
in terms of preference declarations enriches the already 
versatile logic programming paradigm. 

Evaluating the System 
Benchmarks 

Accepted benchmarks for nonmonotonic reasoning sys- 
tems ha ve been realized by the we ll-known TheoryBase 
system (Cholcwihski et al. 1995). This test-bed pro- 
vides encodings of various graph problems in terms of 
default theories and equivalent logic programs. Al- 
though these benchmark problems do not include or- 
dered logic programs, they can nevertheless be used to 
evaluate PLP. The reason for this is given by the fact 
that our method reduces ordered logic programs to reg- 
ular logic programs. Moreover, since ordered logic pro- 
grams agree semantically with regular logic programs if 
no preference information is present, worst-case classes 
for regular logic programs are also worst-case classes for 
ordered logic programs. 

Comparison 

Comparisons between different theorem provers are of- 
ten difficult to realize because of incompatibilities of 
the respective underlying semantics. Even if two sys- 
tems are based on the same formalism, they may rep- 
resent different syntactical fragments rendering signifi- 
cant comparisons nigh impossible. 

A method to address some of these shortcomings is to 
perform comparisons taking the representational power 
of the implemented formalisms into account. That is 
to say, one chooses some "natural" problems, encodes 
it with respect to the specific methodologies associated 
with the implemented formalisms, and uses the resul- 
tant instances as queries of the respective systems. So, 
basically, different systems are compared on the basis of 
(possibly) different representations of the same problem. 
In this sense, PLP can be compared with other logic pro- 
gramming systems, whether or not they do support the 



explicit specification of preference relations. In fact, we 
may even conduct comparisons between PLP and dlv 
or smodels directly, by representing a problem equiv- 
alently with and without the use of ordering relations, 
and so being able to evaluate the representational power 
of explicit preferences. 

Problem Size 

dlv and smodels are state-of-the-art implementations 
successfully demonstrating their respective ability to 
process large and complex problem descriptions. Be- 
cause our compiler is an efficient translator (the resul- 
tant logic programs are polynomial in the size of the 
input program), PLP likewise scales up to real-life prob- 
lem representations. 
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